This invention relates to a change of a configuration of a database and a recovery from a failure of the database, and more particularly to a configuration change and a restoration process for a shared-nothing type database.
As a result of a recent advent of inexpensive blade type computers, there is required a new operation form which configures a server computer (referred to as a blade server hereinafter) by combining plural blade type computers, and carries out processing by employing necessary computer resources within the blade server according to a load variation in the system. For realizing such an operation form, there is required a high-speed mechanism to change the system configuration for infrastructure software typified by database systems, application servers, and Web servers (referred to as middleware hereinafter). Moreover, the system employing the blade type computers has a large number of them in the server, and high scalability is required for the middleware.
A database management system (referred to as DBMS hereinafter), which is typical middleware, upon operating on the plural computers, is categorized into a shared-disk type where disk drives (storage systems) used to store data are shared by the computers, and a shared-nothing type where the respective computers use independent disk drives used to store data. On the shared-disk type DBMS, it is not necessary to care the allocation of data managed by the DBMS to the disk drives, and the system configuration is thus easily changed. However, it is necessary to provide exclusive access control for the computers which have access to a data storage area (referred to as data area hereinafter) on the shared disk, and the scalability is thus limited.
On the other hand, on the shared-nothing type DBMS, data areas are not shared, and the exclusive access control is thus not necessary for the computers, resulting in high scalability.
This type of the DBMS has to provide consistent data management, and thus records update histories (logs) of the data in log storage areas respectively managed by the computers in order to restore the data in case of any failures. For this purpose, a backup of the data areas is obtained at a certain time point, and logs are recorded from this time point. Upon a failure, the data areas are restored to the state at the failure by sequentially applying the stored logs to the backup. This process is referred to as restoration process.
Upon a known restoration process on the shared-nothing type DBMS, logs required for the restoration are obtained from the log storage areas of the respective computers, and these logs are then combined and sorted in the chronological order. The sorted logs are the applied to the backup to carry out the restoration process. (For example, US 2004-0030703 A and pp. 224 to 225 “Guide for New Functions of Oracle9i: Database/Mission Critical System” written by Takashi Kasahara, published by SHOEISHA, Feb. 12, 2002.)